上一篇文章中，咱們已經理解了為什麼 P2P 連線如此的困難，接下來這篇文章咱們將要學習：
WebRTC 是如何進行打洞與連線呢 ?
WebRTC 它主要使用一個名為ICE ( Interactive Connectivity Establishment ) 的框架來進行打洞，它內部整合了 STUN 與 TURN 協議，下面簡單的說明一下這兩個協議。
STUN ( Session Traversal Utilities for NAT ) 中文為 NAT 對談穿透應用程式，它的最主要用處就是幫助在 NAT 內的用戶找到可以連到它的位置。
TURN ( Traversal Using Relay NAT )，它也是一種穿透 NAT 的一樣協議，不過它是使用中繼的方式來進行，通常都是 STUN 的候選位置都無法連線時，才會使用它。
假設目前要連線的雙方情況如下：
A 內網位置：192.168.1.1:5555
B 內網位置：10.10.1.1:7777
A 外網位置(經過 NAT 轉換)：310.110.1.1:9000
B 外網位置(經過 NAT 轉換)：210.210.1.1:7000
TURN Server：111.111.111.111
下圖為示意圖。表示雙方去外部連 Server 時對外的的位置。
接下來咱們就開始進行 ICE 打洞流程。
A 想和 B 進行 P2P 連線
在向 Signaling Server 建立連線請求前前，會先去 STUN Server 收集本機用戶 A 的候選位置，這個位置就是用來給別人可以連到我的位置。
其中候選位置如下 :
上面收集完以候選位置以後 A 就會向 Signaling Server 請求和 B 進行連線，並且附加包含 A 的候選位置的 SDP 給 Server。
用戶 B 從 Signaling Server 收到 A 的連線請求與 SDP 後，也前往 STUN 收集 B 自已的候選位置，為了讓 用戶 A 可以連自已。
用戶 B 取得完自已的候選位置後，它會將這些資訊包含在 SDP 內，回覆給 Signaling Server，然後 Server 在將 B 的 SDP 回覆給用戶 A 。
這時雙方都有了對方的候選位置了。
然後這時雙方 ICE 就會開始使用後選位置來進行嘗試連線。
這裡有件事情要注意：
ICE 會先從本機候選位開始來嘗試，因為如果嘗試成功了，就代表雙方在同一個 NAT 後面，這樣就會直接的使用這個本機候選位來進行 P2P 連線，因為這樣是效能最好的
如果其中一個有成功，那就會開始進行 P2P 連線，然後就可以開始傳送聲音囉。
但如果前三個都失敗了，那就只能選擇備案，那就是使用 TURN Server 那進行中繼連線了，但這樣的確就不算是 P2P 連線了。
通常需要用到 TURN Server 來進行的原因在於：
雙方其中一邊是使用 Symmetric NAT，也就是所謂的對稱形 NAT
最主要的問題就是，這種對稱形的 NAT 它所配置的 PORT 會變。
本篇文章中咱們學到了 WebRTC 的 P2P 打洞技術 ICE，它是一個包含了 STUN 與 TURN 的 NAT 打洞框架，某些情況下，ICE 幾乎可以說是 100 % 的打洞率，因為它最後還有一個 TURN，但是如果真的需要到使用 TURN 的話那就不是 P2P 連線了，這種時後在連麥直播時就會出問題了。
至於有沒有什麼解決方法呢 ? 目前還真想不到呢 ~ 這之後在來研究吧 ~
上面的一些圖片中 IP 有用到 310 的那個，那是錯的，範例應該只到 255，不過我懶的改了，反正只是範例。
iThome鐵人賽
看影片追技術